home *** CD-ROM | disk | FTP | other *** search
/ TPUG - Toronto PET Users Group / TPUG Users Group CD / TPUG Users Group CD.iso / XTRAS / WINUAE / Docs / README.JIT-tuning < prev    next >
Text File  |  2000-12-15  |  8KB  |  178 lines
  1.                 How to get maximum performance out of UAE-JIT
  2.                 =============================================
  3.  
  4. A) How to disable the configuration checks in UAE-JIT
  5. -----------------------------------------------------
  6. If you are reading this, chances are that UAE-JIT told you that your
  7. configuration is suboptimal, and quit. First of all --- if, for whatever
  8. reason (benchmarking?), you want to use such a configuration, you can
  9. disable the check by adding
  10.  
  11.        compforcesettings=yes
  12.  
  13. to your UAE config file. However, please read the rest of this README,
  14. because otherwise you might experience stability problems in addition to
  15. the non-optimal performance!
  16.  
  17.  
  18. B) Most direct memory access
  19. ----------------------------
  20. Part of what makes UAE-JIT fast is that, for most memory accesses, it
  21. replaces UAE's traditional, function call based routines with x86 instructions
  22. that directly access the host memory. In order for this to work, UAE-JIT
  23. performs some slightly convoluted mapping magic, using Linux' SYSV shared
  24. memory segments.
  25. It is possible for that magic to fail. That has two consequences:
  26.  
  27.   * Emulated Memory access will be slower than it could be.
  28.   * More importantly, you might experience occasional crashes.
  29.  
  30. The crashes result from UAE-JIT trying to access Amiga "memory" that in 
  31. reality is an area of memory mapped I/O. UAE-JIT tries to guess which
  32. instructions access I/O and which access real memory, but it can and does
  33. occasionally get it wrong.
  34. Usually (when the magic succeeds), there is a safety net that catches those
  35. mis-guessed accesses, simulates their effect on the emulation, and causes
  36. UAE-JIT to "guess again". THIS SAFETY NET IS UNAVAILABLE WHEN NOT USING THE
  37. MOST DIRECT MEMORY ACCESS, and thus things might crash.
  38.  
  39. Here is a list of reasons why you might experience such problems, sorted
  40. by likelyhood (i.e. most probably, the first one is the reason):
  41.  
  42.   * You are using a large amount of memory for z3mem (like 64MB), and
  43.     your linux kernel has a smaller limit on the maximum size of a 
  44.     SYSV shared memory segment (see "cat /proc/sys/kernel/shmmax").
  45.     Solutions:
  46.       - decrease the amount of Z3 memory
  47.       - increase the maximum size of shared memory segments by issuing
  48.               echo 67108864 >/proc/sys/kernel/shmmax
  49.         while logged in as root. 67108864 is 64MB, i.e. 64*1024*1024.
  50.         Of course, you can set it to other values, if you want to, it
  51.         just has to be at least as large as your Z3 mem
  52.  
  53.   * Your system is generally short on memory
  54.     Solution:
  55.       - Add RAM
  56.       - Add extra swap space
  57.       - Reduce memory sizes in UAE config file
  58.  
  59.   * You are running too old a kernel, which doesn't support some of 
  60.     the needed functionality and/or uses a memory mapping not suitable.
  61.     I am not aware of any such kernels, but I am sure there are some
  62.     Solution:
  63.       - upgrade your kernel ;-)
  64.     
  65.   * Something else
  66.     Solution:
  67.       - add the following lines to your UAE config file:
  68.             comptrustbyte=indirect
  69.             comptrustword=indirect
  70.             comptrustlong=indirect
  71.             compforcesettings=yes
  72.         Performance will be *much* worse than optimal, and crashes are
  73.         still at least possible, though not likely. This should only be
  74.         a last resort, if nothing else helps. If you need to do this,
  75.         please tell me (bmeyer@csse.monash.edu.au) about it (because I
  76.         intend to remove those options eventually if nobody is using them)!
  77.  
  78. In summary, you *really* want to have the most direct memory access
  79. happening!
  80.  
  81.  
  82. C) comptrustxxxx Settings
  83. -------------------------
  84. UAE-JIT "guesses" which emulated 68k instructions access real memory,
  85. and which access memory mapped I/O. Depending on those guesses, it compiles
  86. them into native code differently.
  87. The comptrust* configuration parameters allow you to override those guesses.
  88. If, for example, you put  
  89.  
  90.        comptrustbyte=indirect
  91.  
  92. into your config file, then UAE-JIT will treat *all* byte sized memory accesses
  93. as accessing memory mapped I/O. Of course, this will impact performance.
  94.  
  95. As explained in the previous section, there is now a safety net that 
  96. correctly handles the cases where UAE-JIT guessed "real memory", but reality
  97. was "memory mapped I/O" (such cases would crash earlier versions of UAE-JIT).
  98. Thus, these configuration options are obsolete, and should be left at their
  99. default values of "direct". 
  100. These Options will probably go away sometime in the future, so making sure
  101. you use the default settings will not only give you best performance, but
  102. will also ensure that you won't be unpleasantly surprised when the default
  103. settings become hardcoded behaviour in future versions of UAE-JIT.
  104.  
  105. If you find a reproducable crash while using the most direct memory
  106. access which can be avoided through comptrust* settings, that is a BUG
  107. which I need to know about! In that case, please email a detailed 
  108. description to bmeyer@csse.monash.edu.au.
  109.  
  110.  
  111. D) The compnf Option
  112. --------------------
  113. UAE-JIT tries to avoid generating 68k flags that are never used. Flag
  114. generation (and storage) takes time, so avoiding it when it isn't needed
  115. speeds things up.
  116. However, it is possible that I screwed up, and that it might be over-aggressive
  117. about this --- which might mean that some needed flags are not generated.
  118.  
  119. That's what the compnf ("nf" for "noflags") Option is for. Putting 
  120.  
  121.     compnf=no
  122.  
  123. into your config file (and also "compforcesettings=yes" to make UAE-JIT
  124. accept it) will disable this feature. Of course, it will also reduce 
  125. performance.
  126.  
  127. This option is like the comptrust* options; It will eventually go away,
  128. and the default ('yes') will become hardcoded behaviour. If you find
  129. any software that behaves differently with this set to 'no', it's a bug
  130. and I need to know about it (so that I can fix it).
  131.  
  132.  
  133. E) The cache flush mode
  134. -----------------------
  135. UAE-JIT now tries very hard to avoid recompiling code that doesn't need
  136. a recompile. If you have
  137.  
  138.    comp_flushmode=hard
  139.  
  140. in your config file, all compiled code will get discarded each time the
  141. 68k processor issues an icache flush. That's normally not much of a problem,
  142. but if you are running a Mac emulator inside your Amiga emulator, there
  143. will be lots and lots of cache flushes, and you really really need to use
  144. "soft" rather than "hard".
  145.  
  146.  
  147. F) FPU Emulation
  148. ----------------
  149. JIT FPU emulation is still very new and not very mature. It's almost certain
  150. to be even fuller of bugs than the non-JIT FPU emulation. So if you suspect
  151. that the JIT-FPU emu is causing you problems, put
  152.  
  153.     compfpu=no
  154.  
  155. into your UAE config file. Note that eventually (when things have
  156. matured a bit), UAE-JIT will require the "compforcesettings=yes" to
  157. work without the JIT-FPU, and ultimately the option is likely to
  158. disappear.
  159.  
  160.  
  161. G) Console output
  162. -----------------
  163. Due to its pre-Beta status, UAE-JIT still outputs a lot of info useful
  164. for debugging to the console it was started from. In most cases, that
  165. shouldn't have any significant effects on overall speed, but there
  166. are exceptions.
  167.  
  168. If you suspect that console output is slowing you down, try running
  169. like this:
  170.  
  171.     uae -f config_file  2>/dev/null >/dev/null
  172.  
  173. However, that way you won't get *any* output. In particular, if things
  174. go wrong, and you experience a crash, you won't have any info to mail me,
  175. so it will be much harder for me to fix what caused your crash. So please
  176. only do this if it really helps your performance!
  177.  
  178.